Many applications and engineering domains are increasingly employing a graphical model-based development approach. With the recent availability of graphical modeling notations, methodologies, and tools for domain specific modeling, a graphical model-based development approach has the promise of providing a seamless progression of a system model through the different phases of development. These phases include, for example, preliminary design, analysis and simulation, automated code generation, testing, and system integration.
However, some core technologies need to be developed in order to realize this promise. A key enabling technology is a method for robust and complete generation of code, configuration files, documentation, and other artifacts from graphical models. Model-based development tool suites have made a number of advances in this area in the last decade.
Yet, current approaches to code generation are still limited in their flexibility and customizability for a number of reasons. For example, because graphical models and code generators are separate, yet intricately interrelated, a dual hierarchy has to be maintained. One hierarchy is provided for code generation, and the other hierarchy is provided for the compositional structure of the graphical modeling notation. These hierarchies, although separate, must correspond to one another. Unfortunately, dual hierarchies make development, customization, and verification of code generators difficult. Also, modification of the modeling notation or the code generator in a manner that maintains the consistency between the two hierarchies is difficult.
Moreover, while a number of tools provide support for generating partial code, no tools provide support for complete and robust cross-domain code generation.
Furthermore, different domain specific modeling tools have not been designed to work together to co-generate code, making cross-domain, system wide code generation a burden on the code generator developer.
More specifically, the content of generated code is derived from (a) the structure of the model and (b) the specific values assigned to the properties of model entity instances. Therefore, the structure and semantics of code generator routines are highly dependent upon many details of those modeling notations for which models of interest conform.
All graphical model-based tools utilize modeling notations, and therefore have some kind of meta data. However, often these meta data exist only implicitly in the source code of the tool. For other tools, the meta data are explicitly represented by a meta model.
The relationship between modeling notations and code generators is illustrated by the example shown in FIG. 1. In this example, a graphical model-based tool 10 is composed of both an instance model 12 and an internal meta model 14. In the example of FIG. 1, the unified modeling language (UML) class diagram graphical modeling notation is illustrated for the instance model 12. The UML class diagram concepts are also used to graphically represent the meta model 14.
Meta models, such as the meta model 14, specify the structures and semantics of graphical modeling notations. Instance models, such as the instance model 12, represent instances of legal constructs that conform to some specific graphical modeling notation. Essentially, instance models are built to model systems and solutions while conforming to a modeling notation. An instance model (or simply a model) is a set of modeling entities that form a structure and have values supplied for their attributes. Each modeling entity is associated with a meta-entity via an instantiation relationship. A meta-entity specifies the structure of a modeling entity in the same way that a meta model specifies the structure of an instance model.
In the meta model 14, the class meta-entity 14a defines the meta data for all instances of classes in all models that conform to the modeling notation that the meta model 14 specifies. We refer to the class 14a as the meta-entity for all such class instances. Similarly, the method 14b is the meta-entity for all instances of method modeling entities, and the attribute 14c is the meta-entity for all instances of attribute modeling entities. The meta model 14 indicates that entity instances of type “class” can contain entity instances of type “attribute” and “method.” Therefore, for each class that exists in an instance model, the code generator must be sure to loop over all of its attributes and methods in order to generate their portions of the code. These loops are shown in a call graph 16 depicting the control flow of a code generator.
In general, because the subroutine calling and iteration structures of code generators must be written to correspond to the union of legal model instances, code generators must know the structure of the meta model. Furthermore, these code generators also tend to replicate the structure of the meta model in their own structure. Hence, two separate, but corresponding, structural hierarchies are maintained, one within the code generator and the other within the compositional structure of the graphical modeling notation.
For a simple graphical modeling notation, and for simple forms of code generation, this dual hierarchy technique may be adequate. However, as the complexity of the graphical model and/or required generated code increases, the shortcomings of this dual hierarchy technique become more problematic.
Moreover, the expressiveness of a graphical modeling notation is a limiting factor on the richness of the generated code because every bit of knowledge that can be generated from a model must be specified within the model or must be hard coded in the code generator. Because domain specific graphical modeling notations tend to be deep instead of broad in their expressiveness, domain specific graphical modeling notations limit the nature of the code that can be readily generated.
For example, UML class diagrams specify software structure and, therefore, provide a good foundation for code generation of class and method declarations and shells. However, this graphical modeling notation does not specify information that is necessary for generating behavioral (e.g., method body) code. On the other hand, data flow diagrams support behavioral code generation well but not structural code generation.
The drive for more complete code generation has led to an increase in the demand for new code generation techniques that can link graphical modeling notations together. For example, UML and data flow diagrams (as well as others) could be used cooperatively to describe different aspects of a single (multi-model) software system. Initial work has been done investigating methods for stitching together graphical modeling notations in support of multi-domain, multi-model system graphical modeling techniques. However, this area is still not well understood.
Furthermore, a number of current model-based development tool suites have addressed some of the issues concerning linking together diverse graphical modeling notations in order to generate more complete code for specific application domains. These suites have seen some successes in generating code for specific procedural and/or object-oriented programming languages. However, the graphical modeling notations supported by such tool suites are only internally linked together (i.e., a predefined set of these links are hard-coded in the tool infrastructure). They provide little support for developers to link in new graphical modeling notations from different tools or even extend the way in which supported notations are linked together. Also, these tool suites specialize in generating programming code, but provide less support for generating other types of artifacts, especially when multi-tool cooperation is required.
As an example, a number of diverse embedded systems utilize configuration files to map software components to threads, threads to processes, and processes to hardware, as well as to provide initialization information for distributed system middleware. Typically, configuration files require information specified in more graphical modeling notations than any single tool suite supports. Because there is currently little or no support for the co-generation of configuration files or other cross-domain artifacts between different tool suites, most—if not all—of the complexity regarding how the various tools interact needs to be hard coded in the code generator.
Essentially, the burden is completely on the code generator developer to integrate tools in the interest of cooperative code generation. However, handling complex cross-domain interactions is error prone, and the end product is usually not easily modifiable. These problems are exacerbated when new tools are added, or existing tools are modified, because even small changes may require significant restructuring of affected code generators.
The present invention overcomes one or more of these or other problems.